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ABSTRACT 



One or more filters may be included in each object imple- 
mentation in a CORBA distributed object system. Each 
CORBA server object maintains a registry of filters contain- 
ing unique identifiers and specifications for each of the 
filters and the order in which the filters must be applied. The 
filters execute selected code either before or after the con- 
ventional marshaling and unmarshaling which take place 
during a method invocation in the system. The CORBA 
client object builds a filter registry, from information that it 
received from the server. Filters may also be present in the 
client side of the ORB in order to execute code before and 
after the marshaling and unmarshaling that takes place in the 
client side of the ORB and these latter filters are also 
included in the client filter registry. The client then uses its 
filter registry to invoke the filters during a subsequent 
method invocation. The client also receives a time stamp 
from the server to identify the current filter composition. In 
method invocations to the server, the client includes the 
value of the time stamp it received and the server returns an 
exception to the client if the time stamps do not match. In 
response to this exception, the client re-invokes the 
_retrieve_filtersO method in order to obtain the most recent 
filter registry contents and time stamp from the server. 

73 Claims, 9 Drawing Sheets 
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METHOD AND APPARATUS FOR 
EXECUTING CODE DURING METHOD 
INVOCATION 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

The following U.S. patent applications are related to the 
present application and are incorporated by reference herein 
in their entirety: 

U.S. patent application Ser. No. 08/554,794, filed Nov. 7, 
1995 as a continuation to U.S. patent application Ser. 
No. 07/995,863, filed Dec. 21, 1992 (now abandoned); 
U.S. patent application Ser. No. 08/670,682, filed Jun. 26, 
1996; 

U.S. patent application Ser. No. 08/673,181, filed Jun. 26, 
1996; 

U.S. patent application Ser. No. 08/670,700, filed Jun. 26, 
1996; 

U.S. patent application Ser. No. 08/670,681, filed Jun. 26, 
1996; 

U.S. patent application Ser. No. 08/670,684, filed Jun. 26, 
1996; 

U.S. patent application Ser. No. 08/669,782, filed Jun. 26, 
1996; 

U.S. Patent Application entitled "Method and Apparatus 
for Deferred Throwing of Exceptions in C++", filed by 
Christian J. Callsen and Ken M. Cavanaugh, assigned 
attorney docket no. 6205491 and filed on an even date 
herewith; 

U.S. Patent Application entitled "Method and Apparatus 
for Fast, Local CORBA Object References", filed by 
Christian J. Callsen and Ken M. Cavanaugh, assigned 
attorney docket no. 08/993,800 and filed on an even 
date herewith; 

U.S. Patent Application entitled "Method and Apparatus 
for Constructing Stable Iterators in a Shared Data 
Collection", filed by Christian J. Callsen and Ken M. 
Cavanaugh, assigned attorney docket no. 6016489 and 
filed on an even date herewith; 

U.S. Patent Application entitled, "Method and Apparatus 
for Enforcing Locking Invariants in Multi-Threaded 
Systems", filed by Christian J. Callsen and Ken M. 
Cavanaugh, assigned attorney docket no. 08/993,206 
and filed on an even date herewith; 

U.S. Patent Application entitled, "Method and Apparatus 
for Efficient Representation of Variable Length Identi- 
fiers in a Distributed Object System", filed by Ken M. 
Cavanaugh, assigned attorney docket no. 08/993,204 
and filed on an even date herewith; and 

U.S. Patent Application entitled, "Marshaling And 
Unmarshaling Framework For Supporting Filters In A 
Distributed Object System", filed by Anita Jindal, Ken 
M. Cavanaugh and Sanjeev Krishnan, assigned attor- 
ney docket no. 08/993,263 and filed on an even date 
herewith. 

FIELD OF THE INVENTION 

This invention relates to distributed object systems using 
common object request broker architecture (CORBA) and, 
more particularly, to a method and apparatus for providing 
a filter framework for the execution of code during a method 
invocation. 

BACKGROUND OF THE INVENTION 

Software programs are continually becoming more com- 
plicated. Early programs consisted of straightforward pro- 
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cedural code that presented a simple, command line inter- 
face and text display to the user. These simple programs 
have gradually been replaced with complex programs that 
have graphical user interfaces and multiple features. 

s As programs have grown in complexity, the amount of 
effort which is required to write and debug the programs has 
also increased drastically. Consequently, major efforts have 
been made to reduce the amount of programming necessary 
to produce a modem, full-featured product. One of the most 

10 successful of these efforts has been the development of 
object-oriented programming in which programs are 
designed as collections of discrete elements called "objects". 
The objects can be modified and re -used in many cases, 
thereby reducing the development effort. 

15 As will be understood by those skilled in the art, objects 
in the context of object-oriented programming are software 
entities comprising data and methods or operations on that 
data. The methods of an object collectively form an interface 
for manipulating the data in the object. The objects exist 

20 only at program runtime and are created, or instantiated, 
from object "classes" which are actually written by the 
programmer. The class code written by a programmer can be 
"reused" by another programmer by instantiating objects 
from that code, 

25 In order to further reduce the programming burden, dis- 
tributed object systems have been developed in which 
methods in objects resident on a server can be executed or 
invoked remotely over a network from a client application. 
In this manner, the objects can be developed and maintained 

30 by a party different from the party that developed the client 
application. In such a system information is routed or 
streamed between the client and the server. This information 
includes requests from the client to invoke an object on the 
server and results and data from the method invocation 

35 returning from the server to the client. In addition, object- 
oriented programs often communicate by streaming objects 
from one program to another. 

In such streaming operations, a stream writer organizes, 
or marshals, the information to form a serial data stream. 

40 The serial data stream is then sent to the server where a 
stream reader unmarshals the serial data stream to recon- 
struct a copy of the original information. The stream reader 
must operate such that the unmarshaling exactly "undoes" 
the effect of the marshaling so that the original information 

45 can be reconstructed. Ordinarily, such an operation does not 
present a problem, but when the stream reader is not written 
by the same author as the stream writer there can be 
incompatibilities. 

In order to standardize the marshaling and unmarshaling 

50 and data transfer process, an industry consortium called the 
Object Management Group (OMG) was formed whose 
mission is to define a set of interfaces for inter-operable 
software. Its first specification, the Common Object Request 
Broker Architecture (CORBA) specification, is an industry 

55 consensus standard that hides all differences between pro- 
gramming languages, operating systems, and object loca- 
tion. The CORBA standard defines an object request broker 
(ORB) that handles the marshaling, transport and unmar- 
shaling of information between applications. The ORB 

60 functions as a communication infrastructure, transparently 
relaying object requests across distributed heterogeneous 
computing environments. Inter-operability is accomplished 
through well-defined object interface specifications which 
allow client applications to connect to the ORB. CORBA 

65 provides an implementation independent notation for defin- 
ing interfaces called the OMG Interface Definition Lan- 
guage (IDL). 
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The OMG CORBA specification defines an implementa- filters available on the server, using the _retrieve_filters() 

tion independent object model which is actually built with a method, the server passes the time stamp to the client. In 

programming language, such as C++ or Java. In this model subsequent method invocations to the server, the client 

CORBA objects (also called "servants"), which are implc- includes the value of the time stamp it received. The server 

mented by servers, have references that can be exported lo 5 compares the time stamp in the method invocation to its own 

clients. Clients and servers are roles, not mutually exclusive time stamp and returns an exception to the client if the time 

tasks for a single program, so that any one program can be stamps do not match. In response to this exception, the client 

both a client and a server. Objects and object references are re-invokes the _retrieve_jiltersO method in order to obtain 

typically different programming language objects, although the most recent filter registry contents and time stamp from 

they do not have to be. 10 the server. The client then proceeds to re -invoke the method 

In a server, the implementation of an actual object which usin S the newl y received filter list and time stamp, 

can be used to satisfy an invocation on a CORBA object is In another aspect of the presently preferred embodiment, 

generally both platform and language dependent and various filter code may be downloaded on the client side during 

models are possible for implementing objects in servers. The system operation when the ORB supports class 

original CORBA standard defined a Basic Object Adapter 35 downloading, such as a Java-based ORB. In the Java-based 

(or BOA) which is a framework that adapts the server environment, the application programmer registers both the 

implementation to the implementation independent ORB. A client and server side filter code with an object implemen- 

newer OMG portability standard defines a Portable Object tation. The client side ORB invokes _retrieve_filtersQ 

Adapter (or POA), which replaces the BOA and is intended method and receives an ordered list of filter identifications, 

to be platform independent. Many ORBs also support other 20 The client side ORB then, dynamically loads the filter code 

proprietary frameworks for implementing CORBA objects. from the server using a Java class loader, creates a new 

All of these frameworks are commonly referred to as Object instance of the loaded filter class, and stores the new 

Adapters (or OAs). instance in the client side filter registry. 

An application programmer using object request broker BRIEF DESCRIPTION OF THE DRAWINGS 
technology may want to execute code segments as a part of 

the method invocation process, specifically during the mar- ^ above and forth* advantages of the invention may be 

shaling and unmarshaling processes. Such code segments better understood by referring to the following description in 

may operate to monitor and debug a program, or to imple- conjunction with the accompanying drawings in which: 

ment security mechanisms, for example. Filters, that is, FIG. 1 is a schematic block diagram of an illustrative prior 

sections of code which execute during the method invoca- 30 art hardware platform which forms part of a computer 

tion process before or after marshaling or unmarshaling of system on which the invention can be run. 

arguments in an object request broker system, are known. FIG. 2 is a schematic diagram of a prior art computer 

Filters may be used to perform a variety of tasks, such as network system on which a CORBA system can be built, 

compression, encryption, tracing, or debugging, that may be FIG. 3 is a block schematic diagram illustrating a prior art 

applied to communications to or from an object. However, CORBA environment. 

such filters are typically statically defined for client and FIG. 4 is a block schematic diagram illustrating a CORBA 

server objects and compiled with the client and server code, environment including client and server filters constructed in 

respectfully. accordance with the principles of the invention. 

Simulation, debugging, and other operations would be 4Q FIG 5 is a block schematic diagram illustrating a more 

greatly enhanced if filters could be defined and modified detailed view of the client and server filter registries, in 

during system operation. accordance with the principles of the invention. 

SUMMARY OF THE INVENTION ^ a fl° wcnart illustrating the registration of filters 

in accordance with the principles of the present invention. 

In accordance with the principles of the invention, one or 45 p IGS 7A and 7B com b me to form a flowchart illustrating 

more filters may be included in the skeleton code for each the maintenance of dynamic filter lists in accordance with 

object implementation and each server object maintains a thc principles of the present invention, 

registry of filters containing unique identifiers and specifi- FIG g fa a flowchart iUustrating mc downloading of filter 

cations for each of the filters and the order in which the code b a dfenl - n accordance with the principles of lhe 

filters must be applied. The filters execute selected code 50 orcsent invention 
either before or after the conventional marshaling and 

unmarshaling which take place during a method invocation. DETAILED DESCRIPTION OF THE 

The client includes a filter registry, which is built when PREFERRED EMBODIMENT 

the client side ORB invokes a special method, _retrieve_ FIG. 1 illustrates the system architecture for an exemplary 

filtersO, on a server. In response to a _jetrieve_JiltersO call, 55 client computer 100, such as an IBM THINKPAD 701® 

the server passes the identification of the filters associated computer or Digital Equipment Corporation HiNote™ 

with an object implementation, and the order in which they computer, on which the disclosed network access system 

should be invoked, to the client. The client constructs a (system) can be implemented. The exemplary computer 

registry of filters arranged in the order they should be system of FIG. 1 is discussed only for descriptive purposes, 

applied, and uses this filter registry during subsequent $o however, and should not be considered a limitation of the 

method invocations. invention. Although the description below may refer to 

In accordance with another aspect of the invention, filters terms commonly used in describing particular computer 

may be added to or subtracted from the filter list during systems, the described concepts apply equally to other 

system operation without bringing down the server. The computer systems, including systems having architectures 

server initializes a timestamp to identify the current filter 65 that are dissimilar to that shown in FIG. 1. 

composition and updates the timestamp with each modifi- The client computer 100 includes a central processing unit 

cation to its filter registry. When a client retrieves a list of the (CPU) 105, which may include a conventional 
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microprocessor, random access memory (RAM) 110 for 
temporary storage of information, and read only memory 
(ROM) 115 for permanent storage of information. A 
memory controller 120 is provided for controlling system 
RAM 110. A bus controller 125 is provided for controlling 
bus 130, and an interrupt controller 135 is used for receiving 
and processing various interrupt signals from the other 
system components. 

Mass storage may be provided by diskette 142, CD-ROM 
147, or hard disk 152. Data and software may be exchanged 
with client computer 100 via removable media, such as 
diskette 142 and CD-ROM 147. Diskette 142 is insertable 
into diskette drive 141, which is connected to bus 130 by 
controller 140. Similarly, CD-ROM 147 is insertable into 
CD-ROM drive 146, which is connected to bus 130 by 
controller 145. Finally, the hard disk 152 is part of a fixed 
disk drive 151, which is connected to bus 130 by controller 
150. 

User input to the client computer 100 may be provided by 
a number of devices. For example, a keyboard 156 and a 
mouse 157 may be connected to bus 130 by keyboard and 
mouse controller 155. An audio transducer 196, which may 
act as both a microphone and a speaker, is connected to bus 
130 by audio controller 197. It should be obvious to those 
reasonably skilled in the art that other input devices, such as 
a pen and/or tablet and a microphone for voice input, may 
be connected to client computer 100 through bus 130 and an 
appropriate controller. DMA controller 160 is provided for 
performing direct memory access to system RAM 110. A 
visual display is generated by a video controller 165, which 
controls video display 170. 

Client computer 100 also includes a network adapter 190 
that allows the client computer 100 to be interconnected to 
a network 195 via a bus 191. The network 195, which may 
be a local area network (LAN), a wide area network (WAN), 
or the Internet, may utilize general purpose communication 
lines that interconnect multiple network devices. 

Client computer system 100 generally is controlled and 
coordinated by operating system software, such as the 
WINDOWS 95® operating system (available from 
Microsoft Corp., Redmond, Wash.). Among other computer 
system control functions, the operating system controls 
allocation of system resources and performs tasks such as 
process scheduling, memory management, networking and 
I/O services. 

FIG. 2 illustrates, in a very simple fashion, the connection 
of a number of computing systems, such as that shown in 
FIG. 1, to form a distributed computing facility. Each of the 
individual stations 200, 202, 204, 208 and 210 are intercon- 
nected by a network mechanism. Although the distributing 
computing facility could exist on a single computing system, 
it is more likely to operate over a network transport medium. 
Such a transport medium may be LAN as shown in FIG. 2, 
but may also be other network arrangements, including the 
Internet. All that is necessary is that the terminals 200, 202, 
204, 208 and 210 be able to communicate with each other 
using predefined protocols to exchange information. As 
previously mentioned, the CORBA architecture overlays 
such a network and relieves the individual applications from 
dealing with the details of transporting information over the 
network. More particularly, the CORBA architecture hides 
all of the details and the actual network protocols from the 
application programs. It assures that the application pro- 
grams operate with each other regardless of the platforms on 
which the software is designed to run and regardless of the 
network protocols used to interconnect separate computing 
systems. 
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FIG. 3 illustrates, in a very schematic form, the basic 
CORBA architecture which defines a peer-to-peer distrib- 
uted computing facility where all applications are objects (in 
the sense of object orientation). Objects can alternate 

s between client roles 300 and server roles 302. An object 
operates in a client role 300 when it is the originator of an 
object invocation. An object operates in a server role 302, 
called an object implementation, when it is the recipient of 
an object invocation. 

10 The client 300 communicates with the server 302 by 
means of an object request broker or ORB 308. The ORB 
308 operates with a transport 310 that conveys information 
between the client 300 and server 302 and, as previously 
mentioned, the ORB 308 handles the marshaling, transport 

15 and unmarshaling of information between client 300 and 
server 302. The client 300 communicates with the ORB 308, 
as indicated schematically by arrow 304, by means of an 
implementation independent syntax which describes object 
encapsulations. This syntax is called an interface definition 

20 language (IDL) and is defined in the CORBA specification 
generated by OMG. The OMG interface definition language 
can be used to define interfaces that have attributes and 
operation signatures. The language also supports inheritance 
between interface descriptions in order to facilitate reuse by 

25 developers. Objects or servants in the server 302 export 
object references with interfaces specified by the OMG IDL 
for use by clients. The object reference contains an identi- 
fication of the object implementation so that the server 302 
can pass a request to the correct object. 

30 The entire CORBA architecture is actually implemented 
in a conventional programming language, such as C, C++, 
Java, or Smalltalk. Implementations in a variety of lan- 
guages are available from a number of vendors who typi- 
cally provide an IDL compiler bundled with their ORB 

35 products. The IDL compilers generate header files which 
define the OMG IDL interfaces and can be incorporated into 
application programs. The IDL compilers also generate stub 
code 306 and skeleton code 314 for each interface. 

40 The client application program 300 can link directly to the 
OMG IDL stub code 306. As far as the client application 
program is concerned, an invocation of the stub code 306 
appears to be a local function call. Once invoked, the stub 
code 306 provides an interface to the ORB 308 that performs 

45 marshaling to encode and unmarshaling to decode the opera- 
tion' s parameters into/from communication formats suitable 
for transmission on the transport 310 to/from the server 302. 

At the server side, the OMG IDL skeleton code 314 is the 
corresponding implementation of the OMG IDL interface. 

50 When the ORB 308 receives a request, the skeleton code 314 
unmarshals the request parameters and generates a call, 
indicated schematically by arrow 312, to an object imple- 
mentation in the server 302. When the server completes 
processing of the request, the skeleton code 314 and stub 

55 code 306 return the results to the client program 300. If an 
error has occurred, exception information generated by the 
server or by the ORB is returned. 

An object adapter 316 comprises the interface between 
the ORB 308, the skeleton code 314 and the server 302. 

60 Object adapters, such as adapter 316, support functions, 
such as registration of object implementations and activation 
of servers. There are many potential types of object adapters, 
depending on the purpose of the adapter. The original 
CORBA specification defined only a general-purpose Basic 

65 Object Adapter or BOA. The BOA performs some basic 
functions. For example, when a client request specifies an 
inactive server process, the BOA automatically activates the 
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server process. When the server is activated it registers its 
implementation with the BOA. The BOA then stores this 
registration to use in future object requests. After an object 
is activated, it can receive client requests by means of a 
callback method in the skeleton code 314. BOA services also 5 
include exception handling and object reference manage- 
ment. 

The block schematic diagram of FIG. 4 illustrates the 
addition of filters lo the FIG. 3 ORB architecture. In FIG. 4, 
elements which correspond to elements in FIG. 3 have been 10 
given corresponding numeral designations. For example, 
stub code 306 in FIG. 3 corresponds to stub code 406 in FIG. 
4. On the client side, the client 400 interacts with the stub 
code 406 which, in turn, communicates with the ORB 408. 
The ORB 408 contains implementations of the client side 15 
filters 422-436. On the server side, the object adapter 416 
contains implementations of the server side fillers 438-452. 

Filters are classified in accordance with the relative place 
within a method invocation process where they are applied 
and depending on the type of message to which they are 
applied. Thus, the filters can be categorized as pre-request, 
post-request, pre- reply, and post-reply filters. The pre- 
request filters 422 and 450 are applied before marshaling 
424 of arguments on the client side in a request message and 
before unmarshaling 448 the request arguments in the skel- 25 
eton 414. The post-request filters 426 and 446 are applied 
after marshaling 424 of arguments on the client side and 
after unmarshaling 448 the request arguments in the skeleton 
414. It should be noted that, although only one element is 
shown for each type of filter in FIG. 4, there may actually be 
several separate pre -filters, several separate post-filters, etc. 
Each filter can be separately enabled or disabled. 

Similarly, the pre-reply filters 438 and 434 are applied 
before marshaling 440 of the reply results in the skeleton 35 
414 and before unmarshaling 432 the reply results at the 
client side. The post-reply filters 442 and 430 are applied 
after marshaling 440 of result values on in the skeleton 414 
and after unmarshaling 432 the results at the client side. 

Transform filters may also be employed to implement 40 
encryption and decryption of data or data compression. For 
example, client transform filter 428 could be employed to 
encrypt data which is decrypted by server transform filter 
452 and server transform filter 444 would in turn encrypt 
data which is decrypted by client transform filter 436. There 45 
are two kinds of transform filters supported in the presently 
preferred embodiment of the invention, the request filter and 
the reply filter. The request filters, 428, 452, are invoked on 
the client side after all pre and post filters have been applied 
to the request message and on the server before pre and post 50 
filters are applied to the request message. The reply filters, 
444, 436, are invoked on the server side after all pre and post 
filters have been applied to the reply message and on the 
client side before pre and post filters are applied to the reply 
message. The transform filters are applied only to the 55 
message body, not to the message header, because the object 
which is a part of the message header contains information 
that is required by the object request broker for dispatching 
the message to the appropriate subcontract and for selecting 
what particular transform filters to apply. However, a 60 
dummy message header could be generated in accordance 
with conventional protocols to allow for the application of 
transformation to the message header. This would allow for 
a proper dispatching to the correct subcontract. 

Filters are registered in both the client and the server 65 
before they can be used. The client side filter registry 418 
and the server side registry 420 are illustrated in more detail 



in FIG. 5. As with FIG. 4, elements in FIG. 5 which 
correspond to elements in FIGS. 3 and 4 have been given 
corresponding numeral designations. Generally, the order of 
filter application is important so that finked lists of filters are 
actually registered. The linked list indicates both the filters 
and the their order of application. Filters are implementation 
specific, so that the server side registration takes place at the 
implementation level. The client side registration takes place 
at the object request broker level, since the client is unaware 
of the implementation of an object 

Referring to FIG. 5, the client 500 includes a filter registry 
518 which includes unordered mappings from filter identi- 
fiers 519 and 523 to client filter implementations 521 and 
525, respectively. There is one client filter registry for each 
client process, where each entry includes the filters to be 
invoked on the client side, associating filter names and 
implementations. These could be the filters registered with 

the ORB on the client side using register_JiltersO» °r those 

that are dynamically downloaded from the server. A filter 
implementation group 523 includes ordered filter interface 
lists for pre-filters 554, post-filters 556, and transform -filters 
558. Such lists are preferably created by the ORB in 
response to a _retrieve_filters() invocation. Each client 
object, that is, each client side representation of a CORBA 
object found in a process, has a filter implementation group 
523. In the presently preferred embodiment, the client 
contains a cache which maintains a mapping from object 
implementation identifiers to filter implementation groups. 
The object implementation identifiers include the host name 
of a the server, the server ID, and the implementation ID. On 
the server side, registration takes place on an object imple- 
mentation level. Therefore, the server 502 includes many 
filter registries 520, of which filter registry 1, 560 and filter 
registry 2, 574 are shown. Each registry contains linked lists 
of pre-, post-, and transform filter identifications. For 
example filter registry 560 on the server side, using the 
numbers from the filter implementation group 523 on the 
client side, contains three lists, list 562 corresponding to 
pre-filters, list 564 corresponding to post-filters and list 566 
corresponding to transform-filters. Similarly, filter registry 
574 contains three lists, list 568 corresponding to pre-filters, 
list 570 corresponding to post-filters and list 572 corre- 
sponding to transform-filters. Each of registries 560 and 574 
also contain time stamps 567 and 573, respectively. These 
time stamps are used, as discussed in detaU below, to 
indicate the current composition of the corresponding filter 
registry. 

Two filter registration application programming interfaces 
(APIs): "_register_filter0" and "_remove_filter0" are 
located on the object request broker object which enable 
program developers to register and remove filters on the 
client side. There are four filter registration APIs on the 
server: "_register_filterO", "_register_filter_after()", 
"_register_Jilter_beforeO" and "_remove_fiTterQ". These 
APIs permit the server to register a filter either at a default 
location (the end of the linked list) or relative to a 
previously-registered filter in the list of filter names. The 
remove API removes a specified filter. The filters are reg- 
istered by name and each filter has a unique name which can 
be generated hierarchically. 

The flowchart of FIG. 6 illustrates the server filter regis- 
tration process. Registration begins at step 600, then pro- 
ceeds to decision block 602, where it is determined whether 
more filters are to be registered or not. If there are more 
filters to register, the process proceeds to step 604, where the 
next filter is registered using the APIs described above. From 
step 604, the process returns to step 602. In case there are no 



01/29/2004, EAST Version: 1.4.1 



US 6,249,803 Bl 



10 



more filters to be registered, the process proceeds from step 
602 to step 606, where the server generates a timestamp. The 
timcstamp may be an actual time designation or any other 
designation which indicates a time ordering. For example, 
the timestamp could be a combination of Unix time and the 
process ID, or simply a number which monotonically 
increases. The timestamp is saved with the filter list and 
updated whenever there arc any changes to the filter list. 
After step 606, the process proceeds to its termination at step 
608. 

A client can obtain a list of all filters supported by the 
server's implementation by making the special method call, 
"__retrieve_filters0", to the server. The server returns three 
lists of the names of all pre-, post- and transform filters 
associated with the object implementation. The client can 
then construct a list of filters in the order in which they 
should be applied. In an alternative embodiment, filter lists 
for all implementations can be cached at the host imple- 
mentation ID level. 

In the presently preferred embodiment of the invention, 
the lists of filters can be changed any time, even as the 
system is running. Conventional systems require that the 
server be shut down in order to notify clients of the new filter 
list. Rather than requiring the client to request current filter 
lists each time an invocation is made, the timestamp previ- 
ously mentioned is used to "authenticate" the filter list used 
by the client at the server side before application of the 
filters. Specifically, after the timestamp has been obtained, in 
all subsequent method invocations, the client sends its copy 
of the time stamp to the server in the service context list field 
of the request message. The server retrieves the time stamp 
from the context list field and compares it against its own 
timestamp copy, which it updates with adjustments to the 
filter list. If there is a mismatch in timestamps, the server 
returns an exception to the client and, in response, the client 
re-invokes the "_retrieve__nlters()" method on the server to 
obtain a new filter list and the latest timestamp. The client 
then reinvokes the method, using the new filters and times- 
tamp. 

This process is set forth in a flow diagram of FIGS. 7A 
and 7B which starts at step 700 and proceeds to step 702 
where the client invokes a "_retrieve_filters()" method on 
the server before invoking any other method. In response, 
the server returns the filter lists and time stamp in step 704. 
The filter lists are three lists of filter names: one each for 
pre-filters, post- filters, and transform filters. After returning 
the filter lists, the process proceeds to step 706, where the 
client invokes the method as shown in steps 422 through 428 
in FIG. 4. During the method invocation process, the client 
includes the copy of the time stamp that it obtained from the 
server in step 704 in the service context list of the request 
message. In step 708, the server receives the method invo- 
cation and retrieves its own timestamp, which will have been 
updated to reflect any adjustments to the filter list. 

In step 710, the server compares the time stamp received 
from the client to its own, updated, time stamp. Tie process 
then proceeds, via off-page connectors 714 and 718, to 
decision block 720. The server compares the timestamps 
and, if the timestamps do not match, the process proceeds to 
step 722 where the server returns a "_rebind_filters()'* 
exception to the client. Following the "_rebind_filters()" 
exception, the process proceeds, via off-page connectors 716 
and 712, back to step 702 where the client re-invokes the 
"_retrieve_JilterO" method in order to obtain the latest 
filter list and timestamp from the server, as previously 
described. 

If, in step 720, the time stamps are found to be equal, the 
process proceeds to step 724, where the server processes the 
client method invocation and then proceeds to step 726 to 
finish. 
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In another aspect of the invention, filter code may be 
dynamically downloaded on the client side. In this way the 
client application programmer can use filters without pro- 
gramming them or understand what kind of filters need be 
provided. This type of operation is particularly useful with 
an ORB based on a Java implementation which supports 
class downloading. In such a system, a client programmer 
simply writes a normal application; the Java object request 
broker itself takes care of discovering and applying filters. 
This process is illustrated in the flow diagram of FIG. 8, 
where the process starts in step 800 and proceeds to step 802 
where the client invokes a "_retrieve_filters()" method. 
With this step the client retrieves fully qualified filter names 
from the server. The process then proceeds to step 804 where 
the client employs a Java class loader to download a selected 
filter class. The process then proceeds to step 806 where the 
client creates a new instance of the loaded class using the 
class constructor method. The process then proceeds to step 
808 finish. 

A software implementation of the above -described 
embodiment may comprise a series of computer instructions 
either fixed on a tangible medium, such as a computer 
readable media, e.g. diskette 142, CD-ROM 147, ROM 115, 
or fixed disk 152 of FIG. 1, or transmittable to a computer 
system, via a modem or other interface device, such as 
communications adapter 190 connected to the network 195 
over a medium 191. Medium 191 can be either a tangible 
medium, including but not limited to optical or analog 
communications lines, or may be implemented with wireless 
techniques, including but not limited to microwave, infrared 
or other transmission techniques. It may also be the Internet. 
The series of computer instructions embodies all or part of 
the functionality previously described herein with respect to 
the invention. Those skilled in the art will appreciate that 
such computer instructions can be written in a number of 
programming languages for use with many computer archi- 
tectures or operating systems. Further, such instructions may 
be stored using any memory technology, present or future, 
including, but not limited to, semiconductor, magnetic, 
optical or other memory devices, or transmitted using any 
communications technology, present or future, including but 
not limited to optical, infrared, microwave, or other trans- 
mission technologies. It is contemplated that such a com- 
puter program product may be distributed as a removable 
media with accompanying printed or electronic 
documentation, e.g., shrink wrapped software, pre-loaded 
with a computer system, e.g., on system ROM or fixed disk, 
or distributed from a server or electronic bulletin board over 
a network, e.g., the Internet or World Wide Web. 

Although an exemplary embodiment of the invention has 
been disclosed, it will be apparent to those skilled in the art 
that various changes and modifications can be made which 
will achieve some of the advantages of the invention without 
departing from the spirit and scope of the invention. It will 
be obvious to those reasonably skilled in the art that other 
components performing the same functions may be suitably 
substituted. Further, the methods of the invention may be 
achieved in either all software implementations, using the 
appropriate processor instructions, or in hybrid implemen- 
tations which utilize a combination of hardware logic and 
software logic to achieve the same results. Further, aspects 
such as the size of memory, the specific configuration of 
logic and/or instructions utilized to achieve a particular 
function, as well as other modifications to the inventive 
concept are intended to be covered by the appended claims. 

What is claimed is: 

1. Apparatus for providing a framework for the execution 
of server-specified code at selected points during a method 
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invocation in a distributed object system having clients and operable during the method invocation and the plurality of 

servers, the apparatus comprising: server filters includes a post-filter which executes code after 

a plurality of server filters, each of the server filters having the marshaling and unmarshaling operates. 

an identifier and executing selected code during the U. The apparatus of claim 6 wherein the object request 

method invocation; 5 broker includes a marshaling and unmarshaling mechanism 

a server filter registry in the server object, the server filter operable during the method invocation and the plurality of 

registry containing filter identifiers and a method for server filters includes a pre-filter which executes code before 

retrieving the filter identifiers from the registry; and & c marshaling and unmarshaling operates, a post-filter 

a client filter registry in the client object, the client filter which executes code after the marshaling and unmarshaling 

registry containing filter identifiers, exported from the 10 °P eratcs and transform filters which execute code before the 

server object and stored in the client filter registry in pre-filter operates and after the post-filter operates, 

response to an invocation of the method for retrieving 12. The apparatus of claim 6 wherein the client object 

the filter identifiers wherein the client object can selec- utilizes all the server filters effected in the implementation 

lively invoke one or more of said server filters using the specific code which connects the server object to the object 

filter identifiers in the client filter registry during a later request broker. 

method invocation in the distributed object system. 13. The apparatus of claim 1 wherein each filter identifier 

2. The apparatus of claim 1 wherein the apparatus is unique. 

includes: 14. The apparatus of claim 1 wherein the filter identifiers 

a plurality of filter registries in the server, each registry are hierarchical. 

corresponding to an implementation supported by the 2Q 15. The apparatus of claim 1 wherein the server filter 

server, each filter registry containing filter identifiers registry indicates an order in which the filters are to be 

and a method for retrieving the filter identifiers from invoked. 

the registry; 16. The apparatus of claim 1 wherein the server filter 

a plurality of client filters, each of the client filters having registry and the client filter registry each include an indica- 

an identifier and executing selected code during the 25 tion of parameters required by each filter, 

method invocation; 17- The apparatus of claim 1 further including filter 

a client filter registry in the client, the client filter registry registration application programmer interfaces whereby fil- 

containing filter identifiers and the corresponding client ters ma y be added to > and removed from, the plurality of 

side filter implementations, and filters and the , server filter registry during distributed object 

a filter implementation group in each client object, said 30 svst ern operation. 

filter implementation group including filter lists con- 18 ™ e fPP aratus of claim I 7 wherein the server filter 

taining client side filter implementations, where the includcs a stora & e whl c ch stores aD m*«*on reflect- 

identifiers of the client side filter implementations ing the current composiUon of the plurality of server fitters, 

correspond to the filter identifiers obtained from the . * 9 * ™ e a PP a "tus of claim 18 wherein the server object 

server object that corresponds to the client object in 35 mclude * > . a mechanism which sends the indication to the 

response to the method for retrieving filter identifiers ° ' . 

from the server object. 20 - ^ a PP aratns of claun 19 wherein the cbent object 

3. The apparatus of claim 2 wherein the filter lists include, the indication in the method invocation and the 
correspond to pre filters, post filters, and transform filters. server object includes a mechanism to alert the client object 

4. The apparatus of claim 1 wherein a method invoked on 40 *} ht ****** "> ^ ™ eth °d invocation indicates that the 
the client object also invokes the filters indicated by the <* ent fil , ter does n °| mclude lh ° curreDt composition 
client object's filter lists. of the plurality of server filters^ 

5. The apparatus of claim 1 wherein the client contains a . 21- The apparatus of c aim 1 further composing a mecha- 
filter implementation group cache which maintains a map- I l lsm 1 f or downloading filter code from the server object to 
ping from object implementation identifiers to filter imple- 45 the client object so that the client object can run the filter 
mentation groups, where an object implementation identifier 00 Jl* . , r ... r - 

includes the host name of a server, a server identifier, and an P<: ^method for providing a framework for the execution 

implementation identifier. of client-specified code at selected points during a method 

6. The apparatus of claim 1 wherein the distributed object ^cation in a distributed object system having client and 
system includes an object request broker which transmits the 50 server ob J ects ' the method c °mpr*ing the steps of: 
method invocation from the client object to the server object ( a ) constructing a plurality of server filters, each of the 
and wherein the server filters are located in implementation xrvcT filters havm S ^ identifier and executing selected 
specific code which connects the server object to the object durm g the method invocation; 

request broker. ( D ) constructing a server filter registry in the server object, 

7. The apparatus of claim 6 further comprising a plurality 55 the server filler registry containing filter identifiers and 
of client filters each having an identifier and being located in a method for retrieving the filter identifiers from the 
the object request broker. registry; 

8. The apparatus of claim 7 wherein the client filter (c) constructing a client filter implementation group in the 
registry includes filter identifiers for both the client filters client object, the client filter implementation group 
and the server filters. 60 containing client filter implementations corresponding 

9. The apparatus of claim 6 wherein the object request to filter identifiers exported from server objects and 
broker includes a marshaling and unmarshaling mechanism stored in the client filter implementation group in 
operable during the method invocation and the plurality of response to an invocation of the method for retrieving 
server filters includes a pre-filter which executes code before the filter identifiers; and 

the marshaling and unmarshaling operates. 65 (d) using the client object to invoke one or more filters in 

10. The apparatus of claim 6 wherein the object request the filter implementation group during a later method 
broker includes a marshaling and unmarshaling mechanism invocation in the distributed object system. 
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23. The method of claim 22 wherein step (d) comprises 
the step of: 

(e) using the client object to selectively invoke filters that 
are flagged as optional by said server. 

24. The method of claim 23 wherein the distributed object 
system includes an object request broker which transmits the 
method invocation from the client object to the server object 
and wherein step (a) comprises the step of: 

(al) constructing the server filters in implementation 
specific code which connects the server object to the 
object request broker. 

25. The method of claim 24 further comprising the step of: 
(e) constructing a plurality of client filters each having an 

identifier and being located in the object request broker. 

26. The method of claim 25 wherein step (c) comprises 
the step of: 

(cl) constructing the client filter registry with filter iden- 
tifiers for both the client filters and the server filters. 

27. The method of claim 24 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
operable during the method invocation and step (a) com- 
prises the step of: 

(a2) constructing a pre -filter which executes code before 
the marshaling and unmarshaling operates. 

28. The method of claim 24 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
operable during the method invocation and step (a) com- 
prises the step of: 

(a3) constructing a post-filter which executes code after 
the marshaling and unmarshaling mechanism operates. 

29. The method of claim 24 wherein the object request 
broker includes a marshaling and unmarshaling mechanism 
operable during the method invocation and step (a) com- 
prises the steps of: 

(a4) constructing a pre-filter which executes code before 

the marshaling and unmarshaling operates; 
(a5) constructing a post-filter which executes code after 

the marshaling and unmarshaling mechanism operates; 
(a6) constructing a transform filter which executes code 

before the pre-filter; and 
(a7) constructing a transform filter which executes code 

after the post-filter. 

30. The method of claim 24 wherein step (d) comprises 
the step of: 

(dl) utilizing all the filters effected in the implementation 
specific code which connects the server object to the 
object request broker. 

31. The method of claim 23 wherein step (a) comprises 
the step of: 

(a8) constructing each filter with a unique identifier. 

32. The method of claim 23 wherein step (a) comprises 
the step of: 

(a9) constructing the plurality of filters with hierarchical 
filter identifiers. 

33. The method of claim 23 wherein step (b) comprises 
the step of: 

(bl) constructing the server filter registry to indicate an 
order in which the filters are to be invoked. 

34. The method of claim 23 wherein step (b) includes the 
step of: 

(b2) constructing the server filter registry with an indica- 
tion of parameters required by each filter, and step (c) 
comprises the step of: 

(c2) constructing the client filter registry with an indica- 
tion of parameters required by each filter. 
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35. The method of claim 23 further comprising the step of: 

(f) using filter registration application programmer inter- 
faces to add and remove filters from the plurality of 
filters and the server filter registry during distributed 
object system operation. 

36. The method of claim 35 further comprising the step of: 

(g) storing an indication reflecting the current composi- 
tion of the plurality of server filters in a storage in the 
server object. 

37. The method of claim 36 further comprising the step of; 

(h) sending the indication from the server object to the 
client object. 

38. The method of claim 37 further comprising the steps 
of: 

(i) including the indication in the method invocation; 
(j) receiving the method invocation in the server object; 

and 

(k) alerting the client object if the indication in the 
received method invocation indicates that the client 
filter registry does not include the current composition 
of the plurality of server filters. 

39. The method of claim 23 further comprising the step of: 
(1) downloading filter code from the server object to (he 

client object so that the client object can run the filter 
code. 

40. A computer program product for providing a frame- 
work for the execution of application program -specified 
code at selected points during a method invocation in a 
distributed object system having client and server objects, 
the computer program product comprising a computer 
usable medium having computer readable program code 
thereon including: 

program code for constructing a plurality of server filters, 
each of the server filters having an identifier and 
executing selected code during the method invocation; 

program code for constructing a server filter registry in 
the server object, the server filter registry containing 
filter identifiers and a method for retrieving the filter 
identifiers from the registry; 

program code for constructing a client filter registry in the 
client object, the client filter registry containing filter 
identifiers, exported from the server object and stored 
in the client filter registry in response to an invocation 
of the method for retrieving the filter identifiers; and 

program code in the client object for selectively invoking 
at least one of the server filters using the filter identi- 
fiers in the client filter registry during a later method 
invocation in the distributed object system. 

41. The computer program product of claim 40 wherein 
the distributed object system includes an object request 
broker which transmits the method invocation from the 
client object to the server object and wherein the program 
code for constructing filters comprises program code for 
constructing the server filters in implementation specific 
code which connects the server object to the object request 
broker. 

42. The computer program product of claim 41 further 
comprising program code for constructing a plurality of 
client filters, each having an identifier and being located in 
the object request broker. 

43. The computer program product of claim 42 wherein 
the program code for constructing a client filter registry 
comprises program code for constructing the client filter 
registry with filter identifiers for both the client filters and 
the server filters. 
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44. The computer program product of claim 41 wherein program code for including the indication in the method 
the object request broker includes a marshaling and unmar- invocation; 

shaling mechanism operable during the method invocation program code for receiving the method invocation in the 

and the program code for constructing the plurality of filters server object- and 

comprises program code for constructing a pre-filter which 5 J ' . . 

executes code before the marshaling and unmarshaling program code for alerting the client object if the indica- 

operates. uon * n ^ c received method invocation indicates that 

45. The computer program product of claim 41 wherein me clien * filter registry does not include the current 
the object request broker includes a marshaling and unmar- composition of the plurality of server filters, 
shaling mechanism operable during the method invocation 56. The computer program product of claim 40 further 
and the program code for constructing a plurality of filters 10 comprising program code for downloading filter code from 
comprises program code for constructing a post-filter which the server object to the client object so that the client object 
executes code after the marshaling and unmarshaling can run the filter code. 

mechanism operates. 57. Acomputer data signal embodied in a carrier wave for 

46. The computer program product of claim 41 wherein providing a framework for the execution of application 
the object request broker includes a marshaling and unmar- 35 program-specified code at selected points during a method 
shaling mechanism operable during the method invocation invocation in a distributed object system having client and 
and the program code for constructing a plurality of filters scrvcr objects, comprising: 

comprises. program code for constructing a plurality of server filters, 

program icode for constn.ct.ng a pre-filter which executes Mch of the mr fiUers havi an idemjfler and 

code before the marshalmg and unmarshahng operates; 20 ^ ^ ^ method invoca , ion; 

program code for constructing a post-filter which executes , f ... n< 

code after the marshaling and unmarshaling mecha- P ro f am code [ 0T instructing a server filter registry in 

nism operates* tne server ob J ec U me server filter registry containing 

program code for constructing a transform filter which filter identifiers and a method for retrieving the filter 

executes code before the pre-filter; and 25 identifiers from the registry; 

program code for constructing a transform filter which program code for constructing a client filter registry in the 

executes code after the post-filter. dioni object, the client filter registry containing filter 

47. The computer program product of claim 41 wherein identifiers, exported from the server object and stored 
the program code for invoking at least one of the server in the client filter registry in response to an invocation 
filters comprises program code for utilizing all the filters 30 of the method for retrieving the filler identifiers; and 
effected in the implementation specific code which connects program code in the client object for selectively invoking 
the server object to the object request broker. at least one of the server filters using the filter identi- 

48. The computer program product of claim 47 wherein fiers in the client filter registry during a later method 
the program code for constructing a plurality of filters invocation in the distributed object system, 
comprises program code for constructing each filter with a 35 58. The computer data signal as defined in claim 57 
unique identifier. wherein the distributed object system includes an object 

49. The computer program product of claim 40 wherein request broker which transmits the method invocation from 
the program code for constructing a plurality of filters the client object to the server object and wherein the 
comprises program code for constructing the plurality of program code for constructing filters comprises program 
filters with hierarchical filter identifiers. 40 code for constructing the server filters in implementation 

50. The computer program product of claim 40 wherein specific code which connects the server object to the object 
the program code for constructing the server filter registry request broker. 

comprises program code for constructing the server filter 59. The computer data signal as defined in claim 58 

registry to indicate an order in which the filters are to be further comprising program code for constructing a plurality 

invoked. 45 of client filters, each having an identifier and being located 

51. The computer program product of claim 40 whereiD in the object request broker. 

the program code for constructing the server filter registry 60. The computer data signal as defined in claim 59 

comprises program code for constructing the server filter wherein the program code for constructing a client filter 

registry with an indication of parameters required by each registry comprises program code for constructing the client 

filter, and the program code for constructing the client filter 50 filter registry with filter identifiers for both the client filters 

registry comprises program code for constructing the client and the server filters. 

filter registry with an indication of parameters required by 61. The computer data signal as defined in claim 58 

each filter. wherein the object request broker includes a marshaling and 

52. The computer program product of claim 40 further unmarshaling mechanism operable during the method invo- 
comprising filter registration application programmer inter- 55 cation and the program code for constructing the plurality of 
faces for adding and removing filters from the plurality of filters comprises program code for constructing a pre-filter 
filters and the server filter registry during distributed object which executes code before the marshaling and unmarshal- 
system operation. ing operates. 

53. The computer program product of claim 52 further 62. The computer data signal as defined in claim 58 
comprising program code for storing an indication reflecting 60 wherein the object request broker includes a marshaling and 
the current composition of the plurality of server filters in a unmarshaling mechanism operable during the method invo- 
storage in the server object. cation and the program code for constructing a plurality of 

54. The computer program product of claim 53 further filters comprises program code for constructing a post-filter 
comprising program code for sending the indication from which executes code after the marshaling and unmarshaling 
the server object to the client object. 65 mechanism operates. 

55. The computer program product of claim 54 further 63. The computer data signal as defined in claim 58 
comprising: wherein the object request broker includes a marshaling and 



01/29/2004, EAST Version: 1.4.1 



US 6,249 3 

17 

unmarshaling mechanism operable during the method invo- 
cation and the program code for constructing a plurality of 
filters comprises: 

program code for constructing a pre-filter which executes 

code before the marshaling and unmarshaling operates; 5 
program code for constructing a post-filter which executes 
code after the marshaling and unmarshaling mecha- 
nism operates; 
program code for constructing a transform filter which 

executes code before the pre-filter; and 
program code for constructing a transform filter which 
executes code after the post-filter. 

64. The computer data signal as defined in claim 58 
wherein the program code for invoking at least one of the 15 
server filters comprises program code for utilizing all the 
filters effected in the implementation specific code which 
connects the server object to the object request broker. 

65. The computer data signal as defined in claim 64 
wherein the program code for constructing a plurality of 2 o 
filters comprises program code for constructing each filter 
with a unique identifier. 

66. The computer data signal as defined in claim 57 
wherein the program code for constructing a plurality of 
filters comprises program code for constructing the plurality 2 s 
of filters with hierarchical filter identifiers. 

67. The computer data signal as defined in claim 57 
wherein the program code for constructing the server filter 
registry comprises program code for constructing the server 
filter registry to indicate an order in which the filters are to 30 
be invoked. 

68. The computer data signal as defined in claim 57 
wherein the program code for constructing the server filter 
registry comprises program code for constructing the server 
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filter registry with an indication of parameters required by 
each filter, and the program code for constructing the client 
filter registry comprises program code for constructing the 
client filter registry with an indication of parameters 
required by each filter 

69. The computer data signal as defined in claim 57 
further comprising filter registration application program- 
mer interfaces for adding and removing filters from the 
plurality of filters and the server filter registry during dis- 
tributed object system operation. 

70. The computer data signal as defined in claim 69 
further comprising program code for storing an indication 
reflecting the current composition of the plurality of server 
filters in a storage in the server object. 

71. The computer data signal as defined in claim 70 
further comprising program code for sending the indication 
from the server object to the client object. 

72. The computer data signal as defined in claim 71 
further comprising: 

program code for including the indication in the method 
invocation; 

program code for receiving the method invocation in the 
server object; and 

program code for alerting the client object if the indica- 
tion in the received method invocation indicates that 
the client filter registry does not include the current 
composition of the plurality of server filters. 

73. The computer data signal as defined in claim 57 
further comprising program code for downloading filter 
code from the server object to the client object so that the 
client object can run the filter code. 

* * * * * 
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